Fix Update Dependencies failing when two jobs push to main at once - #584

refusing to allow a GitHub App to create or update workflow
`.github/workflows/update-dependencies.yml` without `workflows` permission

Summary

"Update Dependencies" has failed on and off for weeks — 5 of the last 15 runs, most recently run 33171239370. The dependency updates were never the problem. The three update-npm matrix jobs run in parallel and each commits and pushes straight to main, so whichever pushes second loses the race:

! [remote rejected] main -> main (cannot lock ref 'refs/heads/main':
  is at a466a8ea... but expected 024970fb...)
error: failed to push some refs to 'https://github.com/Cratis/Samples'

fail-fast then cancelled the sibling jobs, so a single lost race took the whole run down and silently dropped the bumps the cancelled jobs had already computed. Every one of the recent failures is this same rejected push.

Fixed

• "Update Dependencies" no longer fails when two of its jobs push to main at the same time (The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582)
• A lost push race no longer discards the dependency bumps the cancelled sibling jobs had already computed (The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582)

Changed

• The npm update matrix runs one folder at a time, and one folder's failure no longer cancels the others (The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582)
• Overlapping workflow runs queue instead of running concurrently (The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582)

Verification

The race and the fix were reproduced end to end locally against real git repositories, using depth-1 clones to mirror actions/checkout@v4:

1. Reproduced the failure — two jobs clone, both commit, one pushes, the second's git pull --rebase && git push is rejected with failed to push some refs. Same failure mode as the CI run.
2. Proved the fix — under the identical race, push-with-retry.sh is rejected on attempt 1, rebases onto the new head, and succeeds on attempt 2. Both folders' updates end up on the remote; neither is lost.
3. Proved it still fails loudly — with an unreachable remote it exits non-zero and emits a ::error:: annotation, so a genuine push problem is not swallowed by the retry.

Repository gates on this branch:

• dotnet build Samples.slnx -c Debug — 0 errors (18 warnings, all pre-existing on main; this PR touches no C#)
• dotnet build Samples.slnx -c Release -p:CratisProxiesOutputPath= — 0 errors
• CI's focused spec set — all green (Backend 4, CrossStore 5, MultiTenancy 9, OperationsDiagnosis 2, Processing 3)

This also disproves the original hypothesis on #582 that a dependency update had broken the build or tests: main builds and tests clean at the current package versions.

Not verified

• The workflow file change has not run in CI, because it could not be pushed (see the blocker above). It is validated only by YAML parse and by the local reproduction of the push behavior.
• The Library Testcontainers specs were not run — they need Docker, which is unavailable in this environment. CI excludes them from its spec set for the same reason.